When we design applications, websites, posters etc - we are essentially building systems that our users would adopt. The choices we make as designers, wether we make navigation menu or add a button, are also the choices we take on behalf of our users.

Now making choices for someone is a hard task. Taking multiple such choices in different orders and vectors is an even harder task. When multiple people in your team are making these choices, it can make it hard to keep tabs on the system you are shipping to the user.

Good systems are built through multiple experiments, learnings, iterations and failures. In this process we might lose track of the overall system that’s shaping up and the computed effect of the choices taken on a day to day basis. So we, as designers, need to more thoughtful and deliberate of these choices.

Right processes and documentation help us be more self aware of the choices we make for our users

Now I can’t help you decide what the right processes are. They are different in different cases, and usually you gotta try a few before one works more than the other. This post is about the some of the things that stops us from investing in these processes and how I got over them.

We read about good processes - Personas, user flows, design systems, copy docs etc --- but usually we dismiss them due to one reason or another - often saying it’s not for me. I used to do the same, until I didn’t. See if one of the reasons is what you tell yourself …

Excuse #1 - It slows me down

The right process should make you go faster. Where we often fall is that we only see speed of the screens that we push out. We miss the other parts of development, shipping and iterations. Good processes reduce the development time, simplify the product hence simplify the features, lower the corrective iterations etc. When we factor in all of this, you would end up saving a lot more than you end up investing.

If you think that following a system has an extra cost associated with it, consider the cost of designing and shipping something bad.

Excuse #2 - It’s pointless for me

If it feels pointless - then it would probably end up being so. There is a high chance you don’t understand the reason behind it, and following it would just not solve the purpose the process was invented for. More important than following a particular process is to know what it’s meant for. If you could understand that, maybe you can figure out another way of achieving the same thing, which works better for your team and product.

Excuses #3 - My team is too small for it

That’s a good thing - isn’t it? Now you don’t have to go through the friction of introducing a new system. You can just sit around on a table, decide on a change and implement it from the next day. Maybe the process you read from one of the bigger design teams might not work with your team, but that does not mean that no process would work.

It took me a while to realise that these methods are merely a tool to enable us make better decisions - and better decisions are as much a part of a smaller team as for a bigger team.

eg : You don’t need to think of a research process from day 0, you need to start talking to users. Just drop a single mail to the first customer. Don’t need to make a library of components, just start making symbols and reusing them in Sketch. Have a single copy doc and not a UX writing manual.

Excuse #4 - Don’t have time to implement it

Your process shouldn’t be an end goal. Wether you are building your design system or organising your copy in one place, don’t think of it as a one time job. Good systems are built by good habits in your team. Keep on iterating over the system, improving it week on week, and it would not feel like an exercise. It would become a way you work. If you make it a task, you might never be able to prioritise it. Rather, if you make it incremental, the system would evolve with time automatically

It’s not just for the designers

This took me a lot more time to realise than it should have. A good design is a function of your entire team, and not just designers. You need the developers to build it right, content people to be consistent, marketing people to set the right brand communication, the product people to facilitate the right product definition and your founders to enable healthy collaboration and communication within the team.

So having a system alone wouldn’t help you build a better product for your users. You need to work through internal team structures, create new processes - some people call it politics, I would rather call it bridging the gap between you and your customers. A good internal process bridges the gap between the customer, business and the team.

Don’t be lazy

Overall - most of the things you read, the methods that bigger teams share - they all have something to teach us. There are always ways of taking the thought process behind them and implementing them in your small team. So stop being lazy, and let’s be more deliberate in our designs.